This invention relates generally to software component interfaces, and more specifically to dynamic mapping of such interfaces.
The evolution of computer software development has included the introduction of new development techniques and methods. These techniques and methods have included new programming languages, new libraries, new development methodologies, and new development environments. Often these techniques and methods are produced to improve software development productivity or to extend software development capability.
Software components are one technique to improve software development productivity and program flexibility. Reusable software components are designed to apply the power and benefit of reusable, interchangeable parts from other industries to the field of software development. Software components have standard interfaces making them interchangeable and reusable. Examples of software components tend to be oriented toward user interface elements. They can be simple like familiar push buttons, text fields list boxes, scrollbars and dialogs, or they can be more complex, such as calculators and spreadsheets.
Microsoft""s ActiveX and the JavaBeans specification are two examples of software component models. ActiveX is a component environment commonly used by applications written in Microsoft""s Visual Basic and Visual C++ programming languages. ActiveX can generally be defined as a specification for a software development methodology and an API that allows software components to be dynamically interchanged. ActiveX makes use of the Component Object Model (COM). Further details of COM are described in Dale Rogerson, xe2x80x9cInside COM,xe2x80x9d 1997 (ISBN 1-57321-349-8) which is hereby incorporated by reference.
The JavaBeans specification for the Java programming language defines an environment for developing components known as xe2x80x9cbeans.xe2x80x9d The JavaBeans specification defines a bean generally as a reusable software component that can be manipulated visually in a builder tool.
ActiveX components (also known as xe2x80x9ccontrolsxe2x80x9d) and beans share the quality that when used within their intended environments, new or alternative components can be substituted for old components without requiring any changes to the application using the component. In addition, software components can be easily incorporated into new programs using software building tools, thereby freeing the developer from writing code to implement the functionality provided by the component.
Unfortunately, the interfaces provided by differing programming environments are not always compatible with one another. The reasons for the incompatibility vary, but common causes are incompatible function parameter passing protocols, incompatible data structure definitions and incompatibilities between programming language conventions between different languages or between different vendors"" compilers for the same programming language. As a result, it is necessary to convert from one interface to another when incompatibilities are encountered. The process of converting the methods, properties and events of a source class, library or language to methods, properties and events of a differing target class, is generally known as mapping. A specific example where mapping is required because of an incompatibility exists when an application designed to use an ActiveX control desires to use a Java bean component.
There are three main reasons why ActiveX controls are incompatible with Java beans. First, the data structures representing ActiveX controls and beans, while containing similar information, are defined differently. These differences include the order of elements in the data structure and the naming convention used for the elements. In addition, elements appearing in one data structure may be missing in the other or may appear in combination with different elements.
Second, the data contained within the object data structure are populated at different times. All of the data required to define an object representing an ActiveX control can be determined at the time the source code is compiled or interpreted. However, in JavaBeans, the data required to define a bean interface object cannot be completely determined through the source code alone. The data that cannot be derived via the source code must be supplied at run-time when the source is interpreted by the Java Virtual Machine (VM). The information that must be supplied by the Java VM generally relates to data type identifiers for the methods, properties and events defined by the bean.
Third, the interfaces defined by the two component models are different. Interfaces are used to connect objects defined by the component model. ActiveX and the JavaBeans specification define their own interfaces to connect their respective objects together. While they perform similar functions, the two interfaces are different and operate on different objects, and are therefore incompatible.
Alternative attempts to allow an ActiveX client to interface with a Java bean have used a technique known as xe2x80x9cstatic mappingxe2x80x9d to map between ActiveX controls and Java beans. Static mapping involves invoking a packager application that gathers data based on user input. The packager application also reads the user specified Java source code and scans the source for bean definitions. When a bean is found, the packager application generates three types of files. The first file type is a Java class file that can be interpreted by the Java VM (Virtual Machine). The second file type is a registry file that must be imported into the registry of the computer running an ActiveX client. The third file type is a type library file that contains a COM compatible definition of the methods, properties and events defined by the bean. The files generated by the packager are populated with data gleaned from scanning the source, and include items such as the public methods, properties and events for the top-level class defined in the bean.
Static mapping has several disadvantages. First, the packager application can only generate mappings for those classes representing beans defined in the Java source code scanned by the application. It is common in object-oriented languages for a class to propagate its methods, properties and events to lower-level classes that inherit from the top-level class. The end result of static mapping is that only the top-level, or explicitly called out Java classes, have ActiveX compatible objects generated. Mappings can only be generated for top-level classes within the bean, mappings cannot be generated for lower-level classes. As a result, it is possible that a significant number of the methods, properties and events that define classes will be inaccessible to a ActiveX client application.
A second disadvantage to static mapping is that the mapping is incomplete. Static mapping methods scan the source code at a particular point in time, and then generate interface files based on the source code. In effect, static mapping produces a snapshot of a bean""s state at a particular point in time. A developer may add methods, properties and events to the bean after the snapshot has been produced by the static mapping method. An ActiveX client using a statically mapped interface will be unable to use the newly defined methods, properties and events.
In addition, as discussed above, there is a significant amount of information about a bean that must be provided by the Java VM, and as a result the information is available only during the run-time of a Java program (i.e. while the Java program is executing on the computer). Since the static mapping method scans the files before the Java program is run, not all of the information that must be supplied at run-time is available to the packager application. As a result, a significant portion of the data describing the bean will not be available when the ActiveX client instantiates the bean, resulting in reduced bean functionality.
A third disadvantage is that static mapping requires additional system management effort. This is because the static mapping information is contained in several files. These files must be installed as a separate step from the installation of Java or ActiveX. In addition, these files must be located in specific directories specified by the registry file in order for the system to work properly. If the user wishes to move these files, additional work is required to insure that the registry entries point to the correct file location.
Therefore, there is a need for a technique that allows software developers to map between component models defined in different development environments that can provide for a more complete mapping of component objects and information within the object, while reducing the development and maintenance overhead of current mapping techniques.
The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification. The invention describes dynamically mapping between class objects representing components defined in two differing software development environments. In one embodiment, a computerized system has an operating system that provides interfaces for controlling two components, with each component interface having methods, properties and events. A client program designed to utilize an interface to one component is combined with a component using a different interface. A mapping from the methods, properties and events of the first interface to the methods, properties and events of the second interface occurs during the run-time of the client program.
Thus, dynamic mapping is a process allowing a client process using a particular component interface definition to use an alternative component defined by a different interface. Dynamic mapping occurs at run-time, when all of the information defining the component is available. The desired bean component object can be queried at run-time to provide the desired interface information. This information can then be used to map the bean""s interface elements to semantically equivalent interface elements used in the client program.
The dynamic mapping described in the present invention provides for advantages not found in systems employing static mapping methods. First, dynamic mapping methods have access to all of the information about the mapped interface at run-time, and the information reflects the component""s current state. For example, dynamic mapping can take advantage of type information describing objects and their constituent elements that is only available at run-time. Because static mapping occurs before the component""s run-time, it does not have access to all of the component""s data, resulting in reduced functionality. In addition, methods, properties and events added to the mapped component after the static mapping process has taken place are not available to a client program.
Second, dynamic mapping has access to methods, properties and events for both top-level class definitions and lower-level class definitions. Because it occurs at run-time, dynamic mapping can query any required object for its methods, properties and event, not just the top-level class object. Static mapping is limited to obtaining information from the source code and the registry, and is therefor only able to acquire data on top-level classes.
Finally, dynamic mapping does not require the use of extraneous files that must be administered and maintained. Dynamic mapping is automatically handled by virtual machines common to many interpreted languages. In contrast, static mapping produces files that must be moved to appropriate directories, imported into the computer""s registry, or interpreted in addition to the source files defining the component. Dynamic mapping avoids this overhead because no extraneous files are produced.
The present invention describes devices, computers, computer-readable media, and systems of varying scope. In addition to the aspects and advantages of the present invention described here, further aspects and advantages of the invention will become apparent by reference to the drawings and by reading the detailed description that follows.